Thanks for tackling this - the diff is small, focused, and easy to review. That said, I agree with the framing in the linked issue that something should give on the 120 cap, but I'd push back on going all the way to 1024. A few thoughts:

Why the cap exists

The 120 ceiling isn't an accident or a forgotten constant - it's doing real work. CLI UX research and most well-designed TUIs converge on ~100–120 columns because:

• Long single-line content (diffs, table rows, code snippets wrapped in boxes) reads worse when stretched. The eye loses the line and re-finds it on every row.
• Side-by-side panels, two-column layouts, and aligned ASCII art only look balanced when the box itself has a known upper bound — otherwise a 300-col terminal gives you a full-width box on the left and a wasteland on the right.
• It caps pathological cases: a user pipes output into a non-TTY reporter that reports columns: 99999, or resizes the window very wide mid-session. Without an upper bound, transient frames can blow up cli-table3 column math in source/markdown-parser/table-parser.ts:51 and the file-ops previews.

So I don't think the right fix is "remove the cap." A configurable, sensible default is.

The middle ground I'd suggest

Something like 160 or 200 for the default - high enough that a 190-col terminal (the exact case from the issue) gets its full ~186 usable columns back, low enough that genuinely wide terminals don't produce comically stretched boxes. Concretely:

• source/constants.ts:50 — DEFAULT_TERMINAL_WIDTH = 160 (or 200)
• source/hooks/useTerminalWidth.tsx:8 — Math.max(Math.min(columns - 4, 160), 40)
• Better still: read it from nanocoder-preferences.json with the constant as the default, which is the third option the issue itself proposes. That sidesteps the "what's the right number" debate entirely.

Let me know your thoughts :)